This invention relates generally to software debuggers and, more particularly, to a method for synchronizing the interaction of multiple debuggers.
Embedded systems programming is the development of programs which are intended to be incorporated on a microprocessor that can be included as a part of a variety of hardware devices. Software for embedded systems is typically developed using a single micro-controller or a digital signal processor (DSP) and either an emulation device or a simulation module to which a debugger is attached. A debugger is a tool which aids a programmer or developer in locating and correcting bugs, i.e., errors. In the case of a simulation module, the simulator and the debugger are implemented in software. In the case of an emulation device, the emulation device is a hardware component and the device driver, which is implemented in software, communicates with the debugger.
FIG. 1 shows a prior art single processor simulation environment. As shown in FIG. 1, a simulator 100 includes a processor model 110 and a debugger 120 which communicates with the processor model 110. The debugger 120 is used to display the state of the debug target (i.e., processor model 110) and to control it, for example, by setting breakpoints or intercepting instructions.
Many embedded software applications are complex and a single micro-processor system, such as the one shown in FIG. 1, may not adequately support such complex applications. Multi-processor systems were created to handle these complex systems. Today, integrated circuits are able to integrate the control of the target. A circuit may contain multiple processors as shown in the prior art multi-processor simulation environment of FIG. 2. Simulator 200 includes three processor models 210a, 210b and 210c. Like the single processor system shown in FIG. 1, each processor model 210a, 210b and 210c communicates with a debugger 220a, 220b and 220c, respectively. Control of the processor models 210a, 210b and 210c is handled by a scheduler 230. It will be appreciated that the scheduler does not exist in the hardware. The scheduler is a simulation artifact. The scheduler""s function is to synchronize the computation of multiple simulation models so that it appears as if they are running in parallel. In the hardware environment, the operation of processors is synchronized by a clock signal. The problem with the multi-processor configuration shown in FIG. 2 is that synchronization is lost when debugging one or more processors in the multi-processor system.
Referring to FIG. 2, a loss of synchronization can be illustrated by the following example. As mentioned above, simulator 200 includes three processor models: processor model A 210a, processor model B 210b and processor model C 210c. The processor models 210a, 210b and 210c are run in debug mode using debugger A 220a, debugger B 220b and debugger C 220c, respectively. The debuggers 220a, 220b and 220c each include a display which shows the current location (address) for the execution state of the processor model 210a, 210b, and 210c, respectively. If the debuggers are put into run mode, the debug display, including the address of the current execution instruction, will not be updated until the run mode is suspended, for example by reaching a breakpoint. In this example, the scheduler 230 causes the processor models 210a, 210b and 210c to execute in lock step. For example, in a given clock cycle, processor model A 210a will execute an instruction, processor model B 210b will execute an instruction and then processor model C 210c will execute an instruction. If one of the processors encounters a breakpoint, processing for all three processor models is suspended at the end of the clock cycle. That is, all of the processors that follow the processor which encountered the breakpoint will execute an instruction in order to complete the cycle. For example, if processor model B 210B encounters a breakpoint, processor model C 210c will execute an instruction in order to complete the cycle. Upon reaching a breakpoint, the debug displays update. Therefore, the debug display for processor model B 210b will be updated when the breakpoint is encountered. Likewise, the debug display for processor model C 210c will be updated. However, the debug display for processor model A 210a will not be updated. Therefore, there is a loss of synchronization because the debug displays do not display the proper information to the user, i.e., processor model A 210a is not showing the correct address. Thus, a need exists which allows for the debugging of a multi-processor system without the loss of synchronization.
In accordance with the present invention, a system for debugging a multi-processor environment operates without loss of synchronization. The system can utilize either a simulator or an emulator. The simulator or emulator includes a scheduler in communication with a number of processor models. Each processor model is representative of a processor which will be used in the target environment, for example an integrated circuit. Each processor model communicates with a debug adapter. Preferably, each processor model communicates with a devoted debug adapter. The debug adapters also communicate with the scheduler and with the debuggers. Preferably, each debug adapter communicates with a devoted debugger.
In accordance with another aspect of the present invention, control commands are routed from the debug adapter to the scheduler and other commands are forwarded from the debug adapter to the associated processor model.
In accordance with yet another aspect of the invention, additional modules may be included in the simulator or emulator, for example, a clock gate module.
In accordance with still another aspect of the invention, communications are accomplished using Application Programming Interface (API) calls.
In accordance with a further aspect of the invention, a processor can execute multiple applications concurrently, i.e., one or more processors can multi-task.